========================================================================= INFO-ATARI16 Digest Tue, 24 Apr 90 Volume 90 : Issue 473 Today's Topics: Hard Disk Case for Sale.. Looking for a Graphics Standard beyond ANSI VDI Possible to Have BACKGROUND IMAGE on Desktop like in Macs? QuickST on the STart Disk ---------------------------------------------------------------------- Date: 24 Apr 90 02:53:17 GMT From: usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!aplcen!jhu nix!ins_bac@ucsd.edu (Ajay Choudhri) Subject: Hard Disk Case for Sale.. Message-ID: <5030@jhunix.HCF.JHU.EDU> I have a hard drive case for sale.. Its pretty big and can handle 1 half height and 1 full height or 3 half heights. anyway it comes with power supply and fan and stuff. This is strictly external, is very rugged. The bays are vertical not horizontal... I'll try and do an ascii representation of the front. ----------------- I I b I I b II I I a I I a II I I y I I y II I I I I II I I 1 I I 2 II I I I I II I I I I II I I I I II I I I I II ----------------- As you can see at my bad attemot, this is pretty big, it is possible to fit two full heights side by side, but the first bay would only 'show' part of the drive. If you need an external drive case with power supply and fan, this is a good choice. Its made by Zenith. My asking price?? 70 dollars.......or trade for miscallaneous IBM,MAC or Atari ST hardware or software e-mail or call me...you actually have a better chance e-mail-ing me I am never home, and my answering machine is not cooperating. but try... -Ajay ins_bac@jhunix.hcf.jhu.edu ins_bac@jhunix.UUCP ins_bac@jhunix.bitnet !uunet!aplcen!jhunix!ins_bac C&P Telephone 301-467-4223(ask for A.J.) Go Yankees, Manchester United, UNLV, NJ Nets, NJ Devils, Dallas Cowboys and Johns Hopkins Lacrosse Bluejays ------------------------------ Date: 22 Apr 90 22:50:20 GMT From: rochester!rit!cci632!ccicpg!felix!art@pt.cs.cmu.edu (Art Dederick) Subject: Looking for a Graphics Standard beyond ANSI VDI Message-ID: <143404@felix.UUCP> In article <1854@dukeac.UUCP> tcamp@dukeac.UUCP (Ted A. Campbell) writes: >So -- is there a limited set of X or MGR graphics/mouse routines that >could be implemented on PCs, allowing me also an easy way to port my >application to other computers, especially workstations? I'd like >very much to hear from you on this. Look at STDWIN. I obtained it from osu-cis. The following is the beginning of the "ABOUT" file. [Last modified on Sat Jul 30 18:04:08 PDT 1988 by gvr] 1. Target systems STDWIN is aimed at C programs. It consists of a few header files (of which only one is visible to the user) and a library. In most cases some system-provided libraries must also be used in the linking phase. Currently, full STDWIN is available for the following environments: (Note that in all cases the code is in beta test state; there may be bugs, functionality may change slightly in the future and new functionality may be added, but the basic framework isn't going to change much.) * X version 11 release 2 * Apple Macintosh using either LightspeedC (2.15) or MPW C (2.02) * Atari ST using Mark Williams C (2.1) * Whitechapel MG-1 running an old version of 4.2 BSD You may volunteer to create a version for your favourite system, or to port it to your favourite C compiler for one of the mentioned micros. A subset emulating most of STDWIN's functionality on an alphanumeric display (this excludes line drawing but includes windows, menus, text editing etc.) is available for: * Any decent Unix that has termcap (tested with 4.?2,3? BSD) * MS-DOS using the Microsoft C compiler (4.0) 2. Getting the full scoop I have written a paper about STDWIN which has been published as a CWI report (Guido van Rossum: STDWIN -- A Standard Window System Interface. Centre for Mathematics and Computer Science, report CS-R8817. Amsterdam, 1988). You might get a copy mailed to you by politely asking our secretary, Marja Hegt . You can also get a source version for any or all of the above-mentioned systems. This is essentially a directory dump of my working version, until I have the time or get some help to prepare a real distribution. It is available through anonymous ftp access to gatekeeper.dec.com, whose IP address is [128.45.9.52]. The directory is pub/stdwin; get the file README for further instructions. A version of the document you're currently reading is in the file ABOUT. Distribution outside the USA is solely by electronic mail. Be prepared to receive up to half a megabyte (in 50K pieces, tarred/ compressed/ uuencoded/ split). If you're interested, write to: gvr@src.dec.com (after October 14, 1988, try once again guido@cwi.nl.) 3. Basic functionality STDWIN allows multiple "full-function" windows, roughly in Macintosh style (title bar, grow box, close box, scroll bars). The appearance of windows is determined by the default of the underlying window manager, and so are other limitations (e.g., overlapping, maximum size, etc.). Windows are dynamically created and destroyed by the application, never directly by the user or the window manager. STDWIN uses a coordinate system derived from the display's coordinate system: (0, 0) is top left, with X pointing right and Y pointing down (these are actually called h and v). Pixel size is that of the display. There are enquiry functions to ask for the display size in pixels and in millimeters. The application is responsible for redrawing the window contents when it is exposed. This is done by associating a "draw procedure" with each window, which knows how to draw the entire window's contents. It gets passed a pointer to the window and the coordinates of the rectangle that needs to be redrawn, so it can (although it needn't) restrict itself to that area. STDWIN guarantees that a window's redraw procedure is only called while the application is waiting for an input event (most implementations simply turn exposure events into calls to the draw procedure). If the application wants to change part of the graphics it is displaying, this is usually done in a two-phase process: first, STDWIN is told that a particular area of the screen must be changed; later, when the application starts waiting for input events again, the draw procedure is called to update the indicated area (and any other area that was exposed or damaged in some way). The application defines the width and height of the area it wants to draw; this needn't bear any relation to the window or screen size. This area is called the "document" although you may also think of it as a virtual window. The actual window generally displays a sub-area of the document; the window's scroll bars indicate the position of the window with respect to the document. The application always uses the coordinates of its document; STDWIN performs the translation to window or screen coordinates are required by the window manager, and ensures clipping of all output to the window. STDWIN is event-based. An application is expected to have a main loop containing a "get event" call followed by a switch on the event type. There is no event mask; an application can simply ignore events it isn't interested in. The most important event types are: ACTIVATE: A window becomes active (keyboard attached and/or topmost) CHAR: ASCII character key pressed (except BS, TAB, CR) COMMAND: special key or function (CLOSE, TAB, RETURN, BS, CANCEL, arrow keys etc.) MOUSE: MOUSE DOWN, MOUSE MOVE (only while down), MOUSE UP; fields in the event record indicate the h, v position, the number of the button, and the "click number" if the event is potentially part of a multiple-click sequence MENU: menu id and item number of a menu selection SIZE: user has resized the window TIMER: the window's timer went off; each window has one programmable timer which can be set to go off at N/10 seconds in the future. When the timer goes off a TIMER event is returned. Currently, STDWIN draws text in a single font. The actual font used depends on the underlying window manager (and can sometimes be influenced by the application programmer and/or the end user in a system-dependent manner). The font may be proportionally spaced, and there are enquiry functions to find out the dimensions of characters and strings. There are functions to draw text and simple lines, rectangles and circles, and ways to erase, shade or invert rectangular areas. There is no way (yet) to do general bitblt operations, or to influence the pen shape. ------------------------------ Date: 24 Apr 90 10:12:01 GMT From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!cs325ec@tu t.cis.ohio-state.edu (Gregory Lemperle-Kerr) Subject: Possible to Have BACKGROUND IMAGE on Desktop like in Macs? Message-ID: <1990Apr24.101201.11155@ux1.cso.uiuc.edu> ia4@cunixd.cc.columbia.edu (Imran Anwar) writes: >Hi. I was wondering if it is possible to have a picture or image in the >background instead of the dull desktop? >I have seen such stuff on the Macs....so obviously it should be available on >a better machine like the ST :-) >Imran Anwar Download degadesk.arc from terminator, it does what you ask... Also switcher.lzh (by moi) will allow you to do what the mac does... randomly select a picture on startup. I used the auto folder program until Gemini (which didn't always work with it) then the accessory until Calamus which doesn't work on the menubar??? There are a couple of versions and the source is included. -- Greg ------------------------------ Date: 21 Apr 90 21:07:56 GMT From: cs.umn.edu!thelake!steve@ub.d.umn.edu (Steve Yelvington) Subject: QuickST on the STart Disk Message-ID: [In article <9004201800.AA18499@xap>, stewart@xyplex.com (Bob Stewart) writes ... ] > I'm typing this via Flash to my Unix system, with QuickST from the May STart > disk running. It leaves cursor blobs all over the place and often doesn't put > the cursor where it belongs. Yucky. I'd feel bad about distributing software > that doesn't work any better than that. Imagine that you're in third grade and you have to walk to school. You have three options: A long, winding route; a shorter route that requires a couple of steep hills, and a shortcut through a few back yards. The trouble with cutting through back yards is that somebody's dog is liable to bite you. One of the back yards QuickST cuts through fouls up VT52 cursor positioning. I don't think the shortcut is worth getting bitten. It screws up the programs that I use most. That doesn't mean it's bad software, but it does make it useless here at the lake, and probably for a lot of other people, too. This is not a new problem, incidentally. I reported it a year or so ago. The response I received indicated that it's a known "feature" -- a tradeoff made when cutting corners. -- Steve Yelvington at the lake in Minnesota steve@thelake.mn.org ------------------------------ End of INFO-ATARI16 Digest V90 Issue #473 *****************************************